REMARKS 

Claims 1 - 3, 1 1 - 13, and 21 - 23 have been amended. Claims 31-33 have been added. 
No new matter has been introduced with these amendments or added claims, which are supported 
in the specification as originally filed. Claims 1 - 33 are now in the application. 

The amendments to independent Claims 1,11, and 21 are directed toward improving the 
readability of the first element, but do not alter the scope of that element. As originally filed, 
dependent Claims 2, 12, and 22 were overly restrictive of Applicants' invention. Therefore, the 
amendments to dependent Claims 2, 12, and 22 remove (to newly-added dependent Claims 3 1 - 
33) the second element of Claims 2, 12, and 22 as originally filed. 

The amendments to independent Claims 3, 13, and 23 are directed toward clarifying the 
references to "host" in the second element; clarifying the third element; and removing the final 
element, which was overly restrictive of the invention. 

With reference to the amendment to the second ("receiving") element of Claims 3, 13, and 
23, the "host" to which this limitation pertains is not the server at which the requests are received: 
it is the host from which the connection request originated. These claims are directed toward 
controlling the number of threads that are concurrently assigned to processing work for any 
particular host, and therefore it is this requesting host that is of interest for the claim language. 
By controlling the number of threads performing work for each host, the likelihood of a failing 
host causing serious degradation to the performance of a server is reduced. See, for example, p. 
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18, lines 13-18 of Applicants' specification, where this is discussed. See also p. 16, lines 18-19 
("... for each distinct host address with which the server application communicates", emphasis 
added) and p. 17, lines 13 - 14. This clarification of the "host" term does not alter the scope of 
these independent claims. 

For clarification, the phrase "individual ones" has been replaced by "an individual one" in 
the third ("retrieving") element of Claims 3, 13, and 23. That is, a single "selected" request is 
only removed by "an individual one" of the threads, even though each individual one may itself 
retrieve other selected ones of the requests. 

With reference to the final ("returning") element of Claims 3, 13, and 23, the requeuing of 
a request (or, more correctly, the requeuing of a connection; see p. 15, lines 2-3 and p. 20, lines 
15 - 16) is not essential to the novelty of Applicants' invention. Therefore, the final element of 
these claims, where this was referenced, has been removed. 

Thus, it can be seen that no new matter has been introduced with the amendments made 

herein. 

I. Drawing Corrections 

Proposed substitute drawings are provided herewith for Figs. 3, 4, and 5. The 
amendments made to these figures are described above in "Amendments to the Drawings". No 
new matter is added with these drawing corrections, which are supported in the specification as 
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originally filed. 

H. Rejection Under 35 U.S.C. S 102(e) 

Paragraph 4 of the Office Action dated April 23, 2003 (hereinafter, 'the Office Action") 
states that Claims 1 - 2, 1 1 - 12, and 21 - 22 are rejected under 35 U.S.C. § 102(e) as being 
anticipated by U. S. Patent 5,761,507 to Govett. This rejection is respectfully traversed. 

Applicants' independent Claims 1 , 1 1, and 21 contain limitations which are not found in 
the Govett reference. The third element of these claims references a "wide queue", which 
comprises "a plurality of queues wherein each of said queues is separately synchronization- 
protected". See Fig. 3, where this wide queue is depicted at element 3 1 0, and comprises (in this 
example) a plurality of queues 311-314. The second element of Applicants' independent Claims 

I, 11, and 21 references "an incoming queue", from which client requests are transferred to the 
wide queue. 

Govett has no teaching of a queue that comprises a plurality of queues. In fact, the same 
queue is referenced in the Office Action for Applicants' limitation of "incoming queue" as is used 
in the citations for Applicants' "wide queue". That is, p. 3 of the Office Action cites col. 7, lines 
9 - 50 as teaching Applicants' incoming queue. What is found in the cited text is a discussion of 
Govett's "request queue 310". Page 3 of the Office Action then cites this same text as teaching 
Applicants' limitations of transferring requests to a wide queue. Obviously, Applicants' claims 
are discussing distinct queues: that is, the incoming queue is distinct from the wide queue. (The 
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transferring from one queue to another is discussed on p. 15, lines 18-20 of Applicant's 
specification.) Thus, Govett's request queue 310 cannot be used as teaching both of these types 
of queues. Furthermore, as stated above, Govett does not teach any queue that is comprised of a 
plurality of other queues, and thus Govett has no counterpart to Applicants' claimed wide queue. 

In analyzing the limitation from Applicants' independent Claims 1,11, and 21 that 
specifies the wide queue is comprised of a plurality of queues, the Office Action cites col. 1 1, lines 
55 - 67 and col. 6, line 53 - col. 7, line 39. The cited text in col. 1 1 describes how a newly-started 
server registers itself with Govett's transaction manager ("XMAN"). This has nothing to do with 
queues. The port mapper is simply informed of the service provided by the new server, if this is 
the first server to be started. (Otherwise, since all of the servers provide an identical service, the 
port mapper already knows what service is provided. See, for example, col. 1 1 , lines 35 - 43.) 
The cited text in cols. 6 and 7 describes how a reference to an inbound request is placed on 
request queue 310, from which an available server will retrieve it. (Col. 6, lines 53 - 59.) That is, 
instead of placing the entire request itself on the server, a handle that refers to the request is 
preferably used, for better performance. (Col. 6, lines 59 - 66.) This text continues by describing 
how a new server is started when it is determined that the number of waiting requests has reached 
the value of a configuration parameter (element 304 in Fig. 3) that controls the starting of new 
servers. (Col. 7, lines 9-17.) However, another configuration parameter is also checked, where 
this other parameter (element 306 in Fig. 3) controls the overall total of running servers. (Col. 7, 
lines 19-21.) When dequeuing requests from request queue 310, the transaction manager is 
responsible for determining which server the dequeued request should be assigned to. (Col. 7, 
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lines 25 - 28.) The remaining text merely describes how requests in request queue 310 advance 
through that (single) queue, and how the determination of whether to start a new server is made 
iteratively. (Col. 7, lines 29 - 39.) 

None of this text discusses a queue of queues, and thus a prima facie case of anticipation 
has not been made out as to Applicants' independent Claims 1,11, and 21. These independent 
claims, as well as their dependent Claims 2, 12, 22, and 31 - 33, are therefore deemed patentable. 
Accordingly, the Examiner is respectfully requested to withdraw the §102 rejection. 

m. Rejection Under 35 U.S.C. S 103(a) 

Paragraph 9 of the Office Action states that Claims 3 - 10, 13 - 20, and 23 - 30 are 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Govett in view of U. S. Patent 
6,427,161 to LiVecchi. This rejection is respectfully traversed. 

As stated above, Applicants' independent Claims 3, 13, and 23 are directed toward 
controlling the number of threads that are concurrently assigned to processing work for any 
particular host. Therefore, the fourth ("determining") element of these claims specifies that a 
check is made to see how many worker threads are already processing work for this host, and the 
fifth ("processing ... if) element specifies that the request is only processed if that number is less 
than some upper limit. Page 5 of the Office Action cites col. 7, lines 9 - 50 of Govett as teaching 
the determining of how many connections exist to a host, as the number of threads currently 
assigned to that host. As explained by the comments above, and as now clarified in these 
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independent claims, the "host" in Applicants' Claims 3, 13, and 23 does not refer to the server 
that is processing the requests - it refers to the requester . (See p. 13, lines 5-7 of Applicants' 
specification, where the term "host" is defined in terms of the entity from which a request was 
received.) The cited text from Govett pertains to how many requests have been received and 
queued on request queue 310, but this text has no discussion of identifying the requesting entity 
from which those requests were received (or of performing any tests or conditional processing 
based on that information). LiVecchi does not teach the limitation of identifying the host from 
which a client request was received, or using an upper limit on the number of connections to a 
particular host in order to determine whether a request can be processed. 

Because the references do not teach the limitations of Applicants' independent Claims 3, 
13, and 23, a prima facie case of obviousness has not been made out as to those claims. These 
independent claims, as well as their dependent Claims 4 - 10, 14 - 20, and 24 - 30, are therefore 
deemed patentable. Accordingly, the Examiner is respectfully requested to withdraw the §103 
rejection. 

IV. Conclusion 

Applicants respectfully request reconsideration of the pending rejected claims, withdrawal 
of all presently outstanding rejections, and allowance of all claims at an early date. 
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Respectfully submitted, 




Attorney for Applicants 
Reg. No. 32,121 
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